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CLOUDFLARE 


Cloudflare Magic Transit 


既 保护 网 络 , 又 提升 性 能 


Cloudflare Magic Transit 为 本 地 、 云 和 混合 网 络 提供 
DDoSs 保护 和 流量 加 速 。 依托 遍布 200 个 城市 的 数据 中 心 
和 超过 51 Tbps 的 DDoS 缓解 容量 , Magic Transit 能 在 
接近 源头 的 位 置 检 测 和 缓解 攻击 , 平均 用 时 不 足 3 秒 , 而 且 
还 附带 了 性 能 方面 的 效益 。 


本 文 将 展示 对 我 们 网 络 运行 的 Catchpoint 测试 的 结果 , 以 
量化 Magic Transit 对 延迟 的 影响 。 测 试 结 果 表 明 , 当 流量 
通过 Cloudflare Magic Transit 路 由 时 , 试验 客户 的 网 络 
性 能 《延迟 和 数据 包 丢 失 ) 得 以 改善 。 具 体 而 言 , 我 们 在 测 
试 结 果 中 发 现 , 流量 通过 Magic Transit 路 由 时 延迟 缩短 
了 3 毫秒 , 数据 包 丢 失 则 几乎 为 零 。 


010 8524 1783 | enterprise@cloudflare.com | www.cloudflare.com/zh-cn/ 


Cloudflare Magic Transit 如 何 做 到 在 不 影响 性 能 的 前 提 下 
保护 网 络 基 础 结构 ? 


在 Magic Transit 诞生 之 前 , 保护 网 络 基 础 结构 免 受 DDoS 攻击 的 策略 主要 有 两 种 : 本 地 硬件 DDoS 防护 
设备 和 云端 清理 解决 方案 。 

在 一 定 程 度 上 , 本 地 硬件 设备 可 以 很 好 地 保护 您 的 基础 结构 。 这些 设备 的 带宽 有 限 , 可 能 会 被 规模 较 大 或 同 
时 发 生 的 攻击 压 垮 。 硬件 也 需要 大 量 前 期 投资 , 而 且 花 费 许多 资源 来 进行 管理 和 维护 。 

云端 清理 中 心 应 运 而 生 , 提供 一 种 更 简单 的 替代 选择 : 使 流量 经 由 清理 中 心 进行 传输 , 并 在 清理 中 心 过 滤 掉 
攻击 流量 。 这 解决 了 本 地 硬件 引起 的 财务 负担 和 维护 难题 。 

然而 , 这 也 造成 了 新 的 问题 : 显著 的 延迟 。 

由 于 这 些 云 提供 商 的 清理 中 心 数量 有 限 , 并 且 分 散 于 不 同 的 地 理 位 置 , 因此 流量 可 能 必须 传输 很 长 距离 以 进 
行 清理 , 然后 才能 到 达 最 终 目 的 地 。 云 提供 商 通常 只 有 屈指 可 数 的 清理 中 心 , 如 果 您 或 最 终 用 户 与 所 有 清理 
中 心 相隔 其 远 , 即使 最 终 目 的 地 就 在 附近 , 流量 也 必须 传输 很 长 一 段 距离 。 这 是 所 谓 的 长 号 效应 , 通常 会 引 
起 明显 且 恼 人 的 延迟 。( 之 所 以 称 为 "长 号 效应 , 是 因为 如 果 您 在 地 图 上 标 出 路 途 较 长 的 往返 路 线 , 其 形状 类 
似 于 长 号 ) 。 
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“清理 中 心 "距离 远 、 数 量 少 , 专门 用 于 缓解 DDoS。 这 需要 网 络 流量 传输 到 备用 数据 中 心 , 以 进行 额外 的 L4-7 处 理 , 从 而 导致 额外 的 延迟 。 
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以 上 述 情况 为 例 , 您 需要 在 第 3-4 层 以 及 第 7 层 服务 (例如 WAF 和 Bot Management 等 ) 中 处 理 流量 。 这 
时 , 您 的 流量 首先 到 达 遥 远 的 L3 清理 中 心 以 缓解 L3 DDoS, 然后 发 送 到 辅助 数据 中 心 以 进行 任何 其 他 L7 
处 理 , 给 端 到 端 流 量 添 加 了 网 络 跃 点 , 引入 了 不 必要 的 延迟 。 如 果 云 供应 商 的 清理 中 心 数 量 有 限 , 并 且 与 网 络 
流量 的 源头 相距 很 远 , 那么 延迟 就 会 特别 明显 。 


Magic Transit 带 来 了 更 好 的 解决 方案 。 我 们 不 使 用 专门 的 清理 中 心 , 而 是 让 Cloudflare 全 球 网 络 中 的 每 个 
数据 中 心 都 能 处 理 清 理工 作 。 实际 上 , 每 个 Cloudflare 数据 中 心 都 运行 完整 的 Cloudflare 服务 堆栈 。 这 样 
一 来 , 您 的 流量 只 需 传 到 最 近 的 Cloudflare 数据 中 心 便 可 ; 我 们 在 100 多 个 国家 /地 区 的 200 多 个 城市 设立 
了 数据 中 心 , 因此 距离 有 可 能 会 很 近 。 
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每 个 Cloudflare 数据 中 心 运行 L3-7 服务 的 完整 堆栈, 因此 网 络 流 量 可 在 同一 人 置 进行 处 理 。 


这 意味 着 , 没有 长 号 效应 , 延迟 也 很 短 。 网 络 性 能 是 我 们 开发 Magic Transit 的 首要 关注 点 ; 我 们 想 确 保 用 户 
不 会 以 性 能 为 代价 来 获得 安全 性 。 


010 8524 1783 | enterprise@cloudflare.com | www.cloudflare.com/zh-cn/ 


Catchpoint 测试 


为 了 验证 这 一 点 , 我 们 使 用 Catchpoint 进行 了 一 些 
响 。 通过 全 局 分 布 探 针 , 我 们 对 位 于 Magic Transit 后 方 的 IP 地 址 和 不 用 Magic Transit 的 另 一 
ICMP ping 测试 , 这 两 个 地 址 都 托管 在 同一 网 络 基础 结构 上 。 这 样 , 我 们 能 够 同时 测量 延迟 、 数 据 包 丢失 和 
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使 用 Magic Transit ( 蓝 色 ) 和 不 用 Magic Transit (灰色 ) 时 的 延迟 (ping 往返 ) 性 能 (毫秒) 
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使 用 Magic Transit ( 蓝 色 ) 和 不 用 Magic Transit (灰色 ) 时 的 运动 性 能 (毫秒 ) 
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使 用 Magic Transit ( 蓝 色 ) 和 不 用 Magic Transit (灰色 ) 时 的 数据 包 丢 失 人 性 能 (百分比 ) 


在 上 


述 测试 中 , 蓝 线 代表 使 用 Magic Transit 时 的 性 能 , 灰 线 则 代表 不 用 Magic Transit 时 的 性 能 。 
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测试 , 以 判断 使 用 Magic Transit 对 整体 网 络 性 能 的 影 
个 地 址 运行 


测试 结果 


性 能 使 用 Magic Transit ( 蓝 色 ) 不 用 Magic Transit (灰色 ) 
延迟 28.96 毫秒 31.98 毫秒 

拌 动 15.61 毫秒 15.24 毫秒 

丢 包 0.52% 5.26% 


这 些 测试 的 重点 


。 使 用 Magic Transit 时 延迟 缩短 了 3 毫秒 
。 使 用 Magic Transit 时 拌 动 增加 了 0.36 毫秒 


。 ”使 用 Magic Transit 时 数据 包 丢 失 几 乎 为 零 (0.52%)， 
而 不 用 Magic Transit 时 则 为 5.26% 


这 些 结果 意味 着 什么 ? 

延迟 : 延迟 是 数据 包 从 网 络 上 的 一 个 点 传输 到 另 一 点 所 花费 的 时 间 。 在 我 们 的 测试 中 , 我 们 观察 到 
Cloudflare 网 络 的 延迟 较 低 。 

Cloudflare 根据 不 同 网 络 路 径 的 状态 不 断 优化 流量 路 由 , 因此 数据 包 从 Cloudflare 到 客户 网 络 的 传 出 路 径 
的 效率 通常 要 高 于 那些 未 经 Cloudflare 优化 的 数据 包 。 

这 可 确保 网 络 延 迟 不 会 延长 , 而 且 如 我 们 的 测试 结果 所 示 , 许多 情形 中 甚至 可 以 缩短 。 这 对 于 对 延迟 敏感 
(实时 ) 的 应 用 程序 尤为 重要 , 例如 在 线 游戏 和 IP 语音 (VolP) 服务 。 

抖动 : 网 络 抖动 是 指 网 络 上 数据 包 传递 之 间 的 延迟 量 。 减少 抖动 对 于 VolP 等 应 用 尤其 重要 。 使 用 Magic 
Transit 时 , 抖动 增加 了 0.36 毫秒 。 即 使 对 抖动 敏感 的 应 用 , 这 也 可 以 忽略 不 计 。 

数据 包 丢 失 : 网 络 传输 中 若 有 一 个 或 多 个 数据 包 未 能 到 达 目 的 地 , 就 会 发 生 数 据 包 丢失 。 根据 具体 的 协议 , 数 
据 包 丢失 可 能 会 造成 需要 花费 额外 时 间 来 重新 传输 , 或 者 导致 质量 下 降 。 对 于 像 视频 会 议 这 样 对 时 间 极 为 敏 
感 的 传输 , 丢 包 率 低 于 1% 被 认为 可 以 接受 *。 在 我 们 的 测试 中 , 我 们 观察 到 Cloudflare 网 络 上 的 丢 包 率 几 乎 
降低 到 了 零 ( 相 比 之 下 , 不 用 Magic Transit 时 的 丢 包 率 超过 了 5%) 

总 之 , Magic Transit 对 延迟 、 抖 动 和 数据 包 丢 失 的 影响 不 会 损害 用 户 体验 , 而 且 在 许多 情况 下 甚至 还 能 改善 
体验 。 换 而 言 之 , Cloudflare 客户 在 使 用 Magic Transit 时 不 必 为 网 络 性 能 “权衡 取舍 "而 操心 。 

此 外 , Cloudflare Magic Transit 可 与 Cloudflare 的 所 有 安全 性 、 性 能 和 可 靠 性 产品 集成 , 进一步 优化 互联 
网 资产 的 性 能 。 


若 要 进一步 了 解 Cloudflare Magic Transit, 请 访问 www.cloudflare.com/magic-transit 
或 通过 以 下 地 址 联系 我 们 : sales@cloudflare.com 


*https://web.archive.org/web/201310100710244/http://sdu.ictp.it/pinger/pinger.html 
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